A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage (NAS) environment, a storage area network (SAN) and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
Storage of information on the disk array is preferably implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of disk space. The disks within a volume are typically organized as one or more groups, wherein each group may be operated as a Redundant Array of Independent (or Inexpensive) Disks (RAID). Most RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate storing of redundant information (parity) with respect to the striped data. The physical disks of each RAID group may include disks configured to store striped data (i.e., data disks) and disks configured to store parity for the data (i.e., parity disks). The parity may thereafter be retrieved to enable recovery of data lost when a disk fails. The term “RAID” and its various implementations are well-known and disclosed in A Case for Redundant Arrays of Inexpensive Disks (RAID), by D. A. Patterson, G. A. Gibson and R. H. Katz, Proceedings of the International Conference on Management of Data (SIGMOD), June 1988.
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on the disks as a hierarchical structure of directories, files and blocks. For example, each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are organized within a volume block number (vbn) space that is maintained by the file system. The file system organizes the data blocks within the vbn space as a “logical volume”; each logical volume may be, although is not necessarily, associated with its own file system. The file system typically consists of a contiguous range of vbns from zero to n, for a file system of size n+1 blocks.
A known type of file system is a write-anywhere file system that does not over-write data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and “dirtied” (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL®) file system available from Network Appliance, Inc., of Sunnyvale, Calif.
The storage system may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access the directories, files and blocks stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. Each client may request the services of the file system by issuing file system protocol messages (in the form of packets) to the storage system over the network. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS) and the Network File System (NFS) protocols, the utility of the storage system is enhanced.
Each data container, such as a file, directory, etc., within a file system is typically associated with an inode that serves as the root of a buffer tree of the data container. The buffer tree is an internal representation of blocks for the data container stored in the memory of the storage system and maintained by the file system. The inode is a data structure used to store information, such as metadata, about the data container, whereas the data blocks are structures used to store the actual data for the container. The inode typically contains a set of pointers to other blocks within the file system. For data containers, such as files, that are sufficiently small, the inode may directly point to blocks storing the data of the file. However, for larger files, the inode points to one or more levels of indirect blocks, which, in turn, may point to additional levels of indirect blocks and/or the blocks containing the data.
Certain events occurring within the storage system and/or a storage operating system executing thereon may result in a message being displayed to an administrator. For example, the storage system may detect that one or more data containers have become corrupted. A pathname provides a way for the administrator to refer to a data container served by the storage system. To that end, each pathname typically represents one data container within the hierarchical structure of the file system. However, the storage system typically reports the identity of the data container to the administrator by using its associated inode number. The inode number is used internally within the file system to identify the inode associated with the data container and, unfortunately, is not easily understood by humans. It is therefore desirous for the administrator to know the pathname of the data container to which the message relates so that appropriate action may be taken. One technique for generating inode to pathname information (I2P) is described in the above incorporated U.S. Pat. No. 7,739,318, entitled SYSTEM AND METHOD FOR GENERATING AND MAINTAINING INODE TO PATHNAME MAPPING INFORMATION, by Edward Zayas, et al. In such an environment, a primary name data structure is included within each inode. The primary name data structure contains information identifying a specific directory entry associated with a primary name of the data container. Illustratively, additional names for a data container, e.g., hard links, may be stored in an alternate name file in a metadata directory within the file system.
In systems that contain I2P mapping information, it is possible for the persistently stored I2P information to become corrupted. For example, memory may become corrupted due to hardware failures. Such memory corruption may be stored as I2P information on disk, thereby resulting in inconsistent I2P information. Other causes of errors may be file system errors and/or data corruption due to errors in applications attempting to retrieve I2P mapping information.
A “brute force” technique for correcting the consistency of I2P information is to delete all of the I2P information and to recompute that information for an entire volume associated with a storage system. A noted disadvantage of such a brute force technique is that in a system with tens or hundreds of millions of data containers, the time required to reconstruct all of the I2P mapping information may be significant. Additionally, while the I2P information is being reconstructed, any commands that attempt to retrieve I2P information will fail.